Configurable interactive assistant

ABSTRACT

The present invention employs branded virtual characters across multiple network platforms throughout various stages of complex transactions (eg, selling insurance). These characters initially engage prospective customers on a network platform, such as a social network, and persist over time across other network platforms (eg, university and company websites) to educate consumers until they are ready to purchase—e.g., from their “trusted advisor”—particular products and services offered by various providers. An extensible configuration tool (“Config Tool”) is provided to simplify the continued development of such a system, as well as customization of individual Product Modules (e.g., a Life Insurance Module) by product and service providers (e.g., insurance companies and employers) and other third-party developers (before and during runtime). This Config Tool provides a variety of extension points permitting virtual characters to be added and their appearance and behavior modified, along with the details of the products and services being offered.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 13/252,926, filed Oct. 4, 2011, entitled“CONFIGURABLE INTERACTIVE ASSISTANT,” which claims the benefit (pursuantto 35 U.S.C. §119(e) for provisional applications and 35 U.S.C. §120 fornonprovisional patent applications) of (i) U.S. Provisional PatentApplication No. 61/289,405, filed Oct. 4, 2010, entitled “InteractiveAssistant API,” which is a continuation of (ii) U.S. patent applicationSer. No. 12/433,720, filed Apr. 30, 2009, entitled “Persistent SalesAgent for Complex Transactions,” each of which is incorporated herein byreference.

BACKGROUND

1. Field of Art

This application relates generally to the field of online sales anddistribution systems and, in particular, to an extensible configurationtool permitting third-party customization of an interactive system thatfacilitates complex transactions by employing branded virtual charactersthat persist across multiple platforms throughout the various stages ofsuch transactions.

2. Description of Related Art

As discussed in U.S. patent application Ser. No. 12/433,720, filed onApr. 30, 2009, there is a need to engage consumers throughout theentirety of a complex sales and distribution process. What is needed isa system that can attract prospective customers and retain themthroughout the various stages of a long and complex sales cycle.Moreover, there is a need to simplify the development process of such asystem, and make it extensible via a user-friendly configuration toolthat permits third-party developers to customize individual productmodules, including the runtime assets contained therein.

SUMMARY

The present invention employs branded virtual characters across multiplenetwork platforms throughout various stages of complex transactions (eg,selling insurance). These characters initially engage prospectivecustomers on a network platform, such as a social network, and persistover time across other network platforms (eg, university and companywebsites) to educate consumers until they are ready to purchase—e.g.,from their “trusted advisor”—particular products and services offered byvarious providers. Even after completing transactions, these characterscontinue to provide various services, such as notifying a customer whosecircumstances have changed of a relevant product or service, whileremaining available to answer questions and provide information upondemand. By employing a semi-automated model, the system of the presentinvention can answer many questions via predetermined vignettes andautomated answers generated by expert systems, while still utilizinglive human experts (often transparently) when necessary.

An extensible configuration tool (“Config Tool”) is provided to simplifythe continued development of such a system, as well as customization ofindividual Product Modules (e.g., a Life Insurance Module) by productand service providers (e.g., insurance companies and employers) andother third-party developers. In one embodiment, this Config Toolprovides a variety of extension points that permit individual charactersto be added and modified, along with their appearance and behavior (atvarious levels of abstraction). Moreover, the interaction among thesevirtual characters can also be customized, including their dialogue andinteractive conversations with users, as well as with one another.Online providers of products and services can also customize theinformation that these virtual characters provide to prospectivecustomers, as well as the manner in which such information is provided.The result is an application that can be highly customized by particularonline providers to target specific demographic groups of prospectivecustomers.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 a is a system diagram of one embodiment of the present invention,illustrating the multiple network platforms and interconnections amongkey system components that enable customers to interact with the systemand engage in complex transactions with multiple service providers.

FIG. 1 b is a block diagram of one embodiment of the server-basedarchitecture of the present invention, illustrating the development anddeployment of Product Modules, including integration with back-endsystems and an extensible Config Tool that enables customization ofvarious aspects of Product Modules by third-party product and serviceproviders and developers.

FIG. 2 is a block diagram of the “Model-View-Controller” paradigmemployed throughout the system architecture of the present invention,and in particular in the development of each Element of the system.

FIG. 3 is a block diagram illustrating the interaction among variousElements of a system Module, triggered by particular Events.

FIG. 4 is a block diagram illustrating one embodiment of the interactionamong various system Elements, including a Main Controller that invokescertain Dialogues (e.g., explanations of concepts to users) andQuestions (e.g., to elicit information from users), and employs variousvisual elements or Overlays (e.g., characters, illustrative images,etc.) accompanied by Audio and Animations (e.g., an animated charactervoicing the Dialogues and Questions to users).

FIGS. 5-9 are screen snapshots illustrating one embodiment of the userinterface of the Config Tool of the present invention, including variouscustomizable aspects of Product Modules.

FIG. 10 is a flow diagram that illustrates one embodiment of the dynamicflow among various components of a Module (Life Module) of the presentinvention, including components of a Life Module Template that can becustomized or swapped for one another via the Config Tool.

FIG. 11 is a block diagram of one embodiment of a Life Module Template,which invokes a Plan Template, including component variables and otherdata structures that can be modified via the Config Tool.

FIG. 12 is a block diagram illustrating sample values for the LifeModule Template and Plan Template of FIG. 11.

FIG. 13 is a block diagram of one embodiment of Character Libraries ofthe present invention, illustrating various components that can beselected to configure the appearance and behavior of Virtual Charactersappearing in one or more Product Modules.

FIG. 14 is a screen snapshot of an initial screen illustrating the userinterface of one embodiment of a Life Module of the present invention.

FIGS. 15 a-15 c are screen snapshots illustrating an opening animationintroducing the concept of life insurance in one embodiment of a LifeModule of the present invention.

FIG. 16 is a screen snapshot of a menu screen illustrating componentElements of one embodiment of a Life Module Template of the presentinvention.

FIG. 17 is a screen snapshot illustrating the results of theconfiguration (via the Config Tool) of a “short” version of an Element(the “What Is It?” Element of one embodiment of a Life Module Templateof the present invention) when a user selects a menu item correspondingto that Element.

FIGS. 18 and 19 a-f are screen snapshots illustrating the results ofconfiguration (via the Config Tool) of an Element (the “Why Should I BuyIt?” Element of one embodiment of a Life Module Template of the presentinvention) when a user selects a menu item corresponding to that Elementand enters an age (25) indicating that they fall within the “Gen Y”demographic group.

FIGS. 20, 21 and 22 a-b are screen snapshots illustrating the results ofconfiguration (via the Config Tool) of an Element (the “Why Should I BuyIt?” Element of one embodiment of a Life Module Template of the presentinvention) when a user selects a menu item corresponding to that Elementand enters an age (55) indicating that they fall within the “BabyBoomers” demographic group.

FIGS. 23 a-f are screen snapshots illustrating the results ofconfiguration (via the Config Tool) of an Element (the “How Does ItWork?” Element of one embodiment of a Life Module Template of thepresent invention) when a user selects a menu item corresponding to thatElement.

FIGS. 24 and 25 a-b are screen snapshots illustrating the results ofconfiguration (via the Config Tool) of an Element (the “How Much ShouldI Buy?” Element of one embodiment of a Life Module Template of thepresent invention) when a user selects a menu item corresponding to thatElement and enters data including their age (25), annual income($75,000) and family coverage preference (spouse and children).

FIGS. 26 and 27 a-b are screen snapshots illustrating the results ofconfiguration (via the Config Tool) of an Element (the “How Much ShouldI Buy?” Element of one embodiment of a Life Module Template of thepresent invention) when a user selects a menu item corresponding to thatElement and enters data including their age (55), annual income($100,000) and family coverage preference (spouse and children).

DETAILED DESCRIPTION I. General Architecture

One embodiment of the architecture of a system of the present inventionis shown in FIG. 1 a. As noted above, this system 100 employs brandedvirtual characters (not shown) to facilitate complex transactions amongmultiple service providers 110 and their customers 120 across multiplenetwork platforms. In this embodiment, the Internet 125 is employed tofacilitate the interconnection of service providers 110 and theircustomers 120 with the multiple network platforms on which the presentinvention may be deployed, including a server-based platform 130 andother network platforms (e.g., social networks) 140 on which clientapplications can be deployed.

It should be noted that the present invention can be deployed entirelyon a single platform (e.g., a social network such as Facebook, a webserver, a company's corporate server, etc.) without departing from thespirit of the present invention. Moreover, the client and serverhardware on which the present invention is deployed, and which serviceproviders 110 and their customers 120 utilize to access the system, caninclude laptops, desktop computers, enterprise servers, mobile phonesand a variety of other computing devices.

FIG. 1 b illustrates one embodiment of the server-based architecture ofthe present invention, centering around the Product Modules 174 withwhich service providers 110 and their customers 120 (shown in FIG. 1 a)interact. System components are divided into different functional phasesof the process, including the development or authoring 160, and thedeployment 170, of Product Modules 174, as well as the integration 180of these Product Modules 174 with various third-party transaction 182and back-end database 185 systems.

Beginning with the authoring stage 160, the entire process is predicatedupon various principles of cognitive science 162, as discussed ingreater detail in U.S. patent application Ser. No. 12/433,720, filedApr. 30, 2009, entitled “Persistent Sales Agent for ComplexTransactions,” which is incorporated herein by reference. Brandedvirtual characters and other programmable objects can be correlated withconcerns of particular customers, based upon demographic/profile orpsychographic/behavioral characteristics of those customers. Rather thansimply offer prospective customers a selection of choices, the systemcan associate those choices with branded virtual characters and otherprogrammable objects that represent likely concerns of customersexhibiting a particular demographic or psychographic characteristic.

For example, because younger users naturally question the need forinsurance, they are more likely to select the “Why do I need insurance?”question, particularly if that question is associated with a youngvirtual cartoon character to which they can relate. Moreover, ananimated virtual character is more engaging than a simple textual link.Similarly, a user that has already demonstrated a risk-taking tendency(eg, by previously selecting and repeatedly playing a game or otherapplication involving high-risk behavior) is more likely to seekinformation relating to the consequences of risky behavior (such as thescope of coverage of a disability policy), whereas a more meticulouslycareful individual is more likely to seek detailed information or askquestions of a live agent.

Whatever correlations the rules dictate, the result is that prospectivecustomers are more likely to be engaged by characters to which they canrelate, and which represent associated concerns that they are likely tohave, based at least in part upon their particular demographic orpsychographic characteristics. Moreover, because cartoon charactersmimic the way in which the human mind actually stores information (eg,by exaggerating and simplifying features, and removing extraneous detailthat would be present in more “lifelike” images), they are distinctiveand readily recognizable, and are thus an effective medium forcommunicating relatively complex educational concepts (such asinsurance). For example, when consumers observe a particular charactersustaining various injuries in different types of accidents, they beginto associate that character with the conceptual issue beingaddressed—eg, “Why do I need insurance?”

Over time, consumers build up a level of trust in these recurringcharacters that would not be present in a typical physical (or evenonline) sales scenario, particularly as they obtain information in alow-pressure sales environment. In some embodiments, these cartooncharacters age over time, along with the consumer, and otherwise adaptto a particular environment. In certain embodiments, branded cartooncharacters are employed intentionally to appear less human than more“lifelike” 3D avatars, which can serve to avoid false expectations ofthe degree of intelligence expected even from semi-automated systems.Trust can be lost quickly if too much reliance is placed on lifelikecharacters that are driven solely by artificial intelligence technology,as a character's lack of actual human intelligence can readily becomeapparent.

This process can in essence become a long-term relationship with acustomer over a lifetime, in which multiple products or services arepurchased over time. Moreover, one or more trusted advisors as well asother associated characters can persist throughout this long process orrelationship.

An authoring tool 165 is employed to assist system developers, as wellas third-party service providers and developers, with the process ofauthoring Product Modules 174. Certain pre-programmed parts 166 andvisualization elements 167 are provided to facilitate this process, suchas character libraries, standard animations, images and dialogue thatpertain to specific types of products (explained in greater detailbelow). Prospective life insurance customers, for example, may generallyhave certain attributes in common, regardless of the particular serviceprovider or life insurance policy. Individual workers face similarscenarios, depending upon their age, family situation, employmentenvironment and a host of other demographic and psychographic data.Moreover, the details of the insurance policies themselves often havemuch in common. Plan templates 168 are therefore provided to facilitatethe authoring process, as will also be explained in greater detailbelow.

Through the use of authoring tool 165, the initial development ofcustomized Product Modules is greatly simplified. However, given thevast array of different types of product offerings that exist acrossvarious industries, third-party providers may not have sufficient timeor resources to invest in custom development of each Product Module 174,particularly as their products and services evolve over time. Moreover,even after a particular Product Module is developed and deployed, thereis often a need to modify the customer experience in interacting withthat Product Module (e.g., due to changes in product offerings,regulatory rule changes, customer behavior, etc).

In one embodiment, third-party providers and developers can continuallyfine-tune and configure individual Product Modules via a Config Tool175, both before and after deployment of a Product Module 174. ConfigTool 175 will be discussed in greater detail below.

Upon deployment 170 of a Product Module 174, the system interacts withcustomers, seeking their input 171 in order to deliver a personalizedexperience 172 to each particular customer. Integration 180 with variousthird-party transaction systems 182, for example, enables customers toenroll in a particular insurance plan. Integration 180 with back-endsystems and databases 185 provides both generic and personalizedinformation that can be delivered to customers in many forms, oftenthrough vignettes including branded virtual characters.

For example, a trusted insurance agent character might interact withcustomers regarding a particular insurance plan by speaking audiodialogue, accompanied by textual and visual data, along with animationsemploying other virtual characters, all in an effort to educateprospective customers regarding various aspects of that insurance plan.By accessing various databases 185, the system will have access not onlyto a relevant knowledge base 187 (containing, for example, details of aparticular insurance plan), but also to behavioral data 186 andactuarial and statistical data 188 relating not only to peoplegenerally, but also to people having similar demographic profiles orexhibiting similar behaviors. This information also includes thebehavior of prospective and actual customers with respect to the systemitself—e.g., which options they select, which products they purchase anda host of other behavioral and statistical data.

Before discussing details of Config Tool 175, and the manner in whichthird-party providers and developers can configure and customize variouscomponents of Product Modules 174, it is helpful to examine thearchitecture and data model underlying the system itself, and thegeneration of these components. In one embodiment of the presentinvention, third-party providers and developers can utilize Config Tool175 to access, configure and customize various core components used toconstruct a Product Module 174. Additional custom components can also beadded when the Product Module 174 is compiled, or even dynamically atruntime. A consistent syntax in the data formats facilitates theconstruction of “editors” (e.g., visual editors) used to develop coreand custom components.

A Product Module 174 is divided into components which are each composedof smaller units, called “Models”, “Views”, and “Controllers.” The“Model-View-Controller” paradigm is a common way of breaking apart thedata representation (Model), the module's user interface (View), and thecode which mediates between them and the user (Controller).

Controllers determine how a Product Module 174 progresses over time,passing Events (messages to invoke actions) to other Controllers or toViews, which are the visual elements of a module. Views respond toEvents, while Models contain small pieces of data, such as preferences,recent user history and visual settings. Controls are parts of a View,such as a UI (user interface) widget. Forms are special Controls thatcan contain one or more other Controls and which convey data to users.

A simple diagram of an Element 200 or Plugin of the system isillustrated in FIG. 2. The Controller 210 scripts dictate theinteraction with users, and how data (Model 220) is extracted via the UIelements 230 (Forms, Views and Controls). Multiple Elements (e.g., 310,320, 330 and 340) then interact with one another, triggered by variousEvents 350, as illustrated in FIG. 3. A more concrete example isillustrated in FIG. 4, in which a particular Element, such as a MainController 410, invokes certain Dialogues 420 (e.g., explanations ofconcepts to users) and Questions 430 (e.g., to elicit information fromusers), each of which can include various visual elements or Overlays440 (e.g., characters, illustrative images, etc.) accompanied by Audio450 and Animations 460 (e.g., an animated character speaking theDialogues and Questions to users). While under the control of MainController 410, various Elements of FIG. 4 may also be triggered viapredefined Events 470. Moreover, additional Elements or Plugins 480 maybe added to the system at any time, e.g., via the Config Tool (notshown).

In one embodiment, the following set of six core components areavailable to third-party providers and developers:

-   -   Step    -   Dialogue    -   Question    -   Response    -   Overlay    -   Form (including NumberForm, TextForm, RadioForm and EmptyForm)

Steps (not shown in FIG. 4) are subsections of a script (such as MainController 410), representing a distinct “scene” or idea. In thisembodiment, a Step includes at least one Question and may also containone or more Dialogues. For example, a simple Step might include a singleDialogue and one Question which has two possible Responses (also notshown in FIG. 4), and would look like the following:

<object type=“com.trustnode.assistant.models.Step”>   <propertyname=“id” value=“2”/>   <property name=“preDialogues”>     <array>      <object type=“com.trustnode.assistant.models.Dialogue”>      <property name=“animationUrl”value=“assets/animations/scene3.swf”/>         <property name=“lines”>          <array>             <objecttype=“com.trustnode.assistant.models.Line”>               <propertyname=“text”>                 <string>Some basic dialogue.</string>              </property>             </object>           </array>        </property>       </object>     </array>   </property>  <property name=“question”>     <objecttype=“com.trustnode.assistant.models.Question”>       <propertyname=“form”>         <objecttype=“com.trustnode.assistant.controls.RadioForm”>           <propertyname=“autoPosition” value=“true”/>         </object>       </property>      <property name=“responses”>         <array>           <objecttype=“com.trustnode.assistant.models.Response”>             <propertyname=“text” value=“Answer 1 (leads to next)”/>             <propertyname=“next” value=“3”/>           </object>           <objecttype=“com.trustnode.assistant.models.Response”>             <propertyname=“text” value=“Answer 2 (leads to next)”/>             <propertyname=“next” value=“3”/>           </object>         </array>      </property>     </object>   </property> </object>

Dialogues 420 are non-interactive sets of animation, audio and text.Dialogues 420 typically are used to illustrate a point or educate theuser. Any number of characters may talk during a Dialogue 420, butHarvey (the primary “virtual agent” in this embodiment) usually is theone to talk to the user or narrate. Dialogues 420 may appear before aQuestion 430 or after a Response. Another example of a simple Dialogue420 is the following:

<object type=“com.trustnode.assistant.models.Dialogue”>   <propertyname=“animationUrl” value=“assets/animations/   scene1.swf”/>  <property name=“lines”>     <array>       <objecttype=“com.trustnode.assistant.models.Line”>         <propertyname=“text”>           <string>Hi, I'm Harvey Keck, your          virtual insurance guide.</string>         </property>      </object>     </array>   </property> </object>

Questions 430 prompt users for input (e.g., Responses). In oneembodiment, a Form may contain an animation and audio representing anaudio cue to the user (e.g., Harvey asking a question). Each Question430 contains a Form and any number of Responses, such as the following:

<property name=“question”>   <objecttype=“com.trustnode.assistant.models.Question”>     <propertyname=“animationUrl” value=“assets/animations/scene2.swf|blue”/>    <property name=“lines”>       <array>         <objecttype=“com.trustnode.assistant.models.Line”>           <propertyname=“text”>             <string>FINALLY! A question!</string>          </property>         </object>       </array>     </property>    <property name=“form”>       <!--         RadioForm can beauto-positioned, which         means that the responses will be stacked        predictably. You can still position them         relatively.      -->       <objecttype=“com.trustnode.assistant.controls.RadioForm”>         <propertyname=“autoPosition” value=“true”/>       </object>     </property>    <property name=“responses”>       <array>         <objecttype=“com.trustnode.assistant.models.Response”>           <propertyname=“text” value=“Start from Beginning”/>           <propertyname=“next” value=“1”/>         </object>         <objecttype=“com.trustnode.assistant.models.Response”>           <propertyname=“text” value=“Go to the next step”/>           <propertyname=“next” value=“2”/>         </object>       </array>     </property>  </object> </property>

A Response represents a potential way a user might respond to a Question430. A Response can include a range of user responses, or a specificresponse. If the user fails to respond, a default response can beemployed. Each Response ends with a link to a “next” desired Step.

Overlays 440 are animations that can be substituted for the defaultanimations provided by the system—e.g., to allow more customizability,or to add additional characters to a scene without recompiling any code.The use of “layers” allows for Overlays 440 to be placed in front of orbehind other objects. Default Overlays 440 are used to place UI elementson the screen. In one embodiment, an Overlay 440 can be displayed for aspecified duration of time or number of Steps, or indefinitely.Following is an example of a set of default Overlays 440:

<property name=“defaultOverlays”>   <array>     <objecttype=“com.trustnode.assistant.models.Overlay”>       <propertyname=“animationUrl” value=“assets/animations/DEFAULT_BACKGROUND.swf”/>      <property name=“removeAfterComplete” value=“false”/>      <property name=“removeAfterStopped” value=“false”/>      <property name=“layerName” value=“backgrounds”/>     </object>    <object type=“com.trustnode.assistant.models.Overlay”>      <property name=“animationUrl” value=“assets/      animations/ui.swf”/>       <property name=“removeAfterComplete”value=“false”/>       <property name=“removeAfterStopped”value=“false”/>     </object>   </array> </property>

Forms are a set of UI Controls that (in one embodiment) are displayedduring a Question 430. They allow the user to input a Response that getsparsed to change the flow of the module. Forms can be customized toallow potential new ways for the user to respond. For example, one couldcreate an “Upload Form” to allow a user to upload a photo or scans ofinsurance information. Another custom Form could be a “plan calculator”which could allow for a sophisticated multi-Step Question 430 whichcould calculate premiums for a user.

As will be discussed below with respect to Config Tool 175, the presentinvention is extensible at a variety of “extension points” includingControllers (e.g., to change the control flow of a module),Views/Controls/Forms (e.g., to add new UI elements and new ways forusers to respond), Models (e.g., to store new types of data), Styles(e.g., custom CSS styles), and Tags (e.g., custom XML tags to add newfeatures or simplify data representation). In one embodiment, use of theParsley Framework also provides various extension points withoutaccessing internal source code.

Plan Templates are employed to facilitate rapid customization ofindividual aspects of plans (e.g., the amount of the deductible for aparticular insurance policy). Module Templates permit configuration andcustomization of various different component Elements of a ProductModule, beyond the design of individual product or service plans.Moreover, “Presets” enable third-party providers and developers to groupmultiple different configurations (e.g., swappable Elements), therebyfurther simplifying the process of configuring and customizing a ProductModule. Each of these concepts is discussed in greater detail below.

II. Config Tool

FIGS. 5-9 illustrate one embodiment of the user interface of the ConfigTool 175 of the present invention, including various customizableaspects of Product Modules, in this case insurance-related products. Itshould be appreciated that many other aspects of Product Modules (acrossvarious industries) can be configured and customized by third-partyproviders, companies and developers through the user interface of a toolsuch as Config Tool 175, as well as via an Application ProgrammingInterface (API) that provides third-party software access to suchfunctionality.

The screen snapshot in FIG. 5 illustrates the UI 500 of Product Tab 510of Config Tool 175, presented in the window of a web browser (withstandard web browser controls 515 in this embodiment. A user (e.g., athird-party insurance provider), upon selecting a product category 520such as Medical products 520 a, is presented with a list of availableproducts 530 from which to choose, all of which fall under the Medicalproducts 520 a umbrella. In this embodiment, available products 530encompass all of the medical products 520 a offered by the provider viathis system.

Note that an individual Product Module might include one or more ofthese products or plans, both within and across different productcategories 520. Regardless of the grouping of products within a ProductModule, Config Tool 175 permits users to customize (in this embodiment)certain aspects of individual products or plans, as well as more globalaspects within and across Product Modules. In one embodiment, eachproduct category 520 corresponds to a Product Module. For example, aMedical Module might include one or more medical products selected fromamong the list of available products 530 (but no products from othernon-medical categories, such as dental, vision, etc).

The purpose of UI 500 is to enable a user/provider to determine whichproducts to include for a particular deployment. For example, aninsurance provider might offer both HMO and PPO products to employees ofone particular company, but only HMO products to employees of anothercompany. In the example illustrated in FIG. 5, the user has previouslyselected both HMO and PPO products from the list of available products530, and added them (e.g., via Add button 540) to the list of selectedproducts 560 to be included in this deployment. Similarly, Remove button550 may be used to remove a product from the list of selected products560. In other embodiments, a product might only be visible in either thelist of available products 530 or selected products 560 (rather thanalways remaining visible in the list of available products 530). This ispurely an implementation decision.

Note that the list of selected products 560 also includes other productsoutside of the Medical category 520 a. For example, no products have yetbeen selected from the Dental category 520 b, while Vision Plan A waspreviously selected from Vision category 520 c. Similarly, Term Life wasselected from Life category 520 d, while Vol STD was selected fromDisability category 520 e.

Having selected which of the available products 530 across the variousproduct categories 520 to include in a particular deployment, auser/provider may then configure various global presentation-relatedaspects for one or more Product Modules, as shown in FIG. 6, whichillustrates one embodiment of a Presentation tab 610 of Config Tool 175.In one embodiment, UI 600 assumes that a particular Product Module hasalready been selected. In other embodiments, UI 600 could include a listof Product Modules (or individual products or plans within a ProductModule) to which the presentation-related configuration would apply.

In the embodiment illustrated in FIG. 6, a user can select from amongmultiple Menu Types 620, including the “Main Menu” configuration showntherein. For example, as will be illustrated below with respect to asample Life Module, a “Main Menu” option may be used to combine multipleProduct Modules into a “Menu Module” to permit navigation amongdifferent product offerings. Other options can include different menutitles, different sets of menu items, or various different levels ofmenus and sub-menus. Additional Display options 630 are provided, suchas whether the Product Module is an “Expanding” Module as well as thesize of each screen (e.g., a 640×480 window). Moreover, variousNavigation options 640 are included, such as a Plan Summary button 640 a(to enable users to see summary information regarding a particularinsurance product or plan), Back and Skip buttons 640 b (to enable usersto repeat or skip certain Elements of a Product Module, such as sectionof Dialogue), a Quote button 640 c (to enable users to obtain animmediate quote for a particular insurance product or plan, based uponinformation previously provided—e.g., by redirecting users to aparticular URL) and an Enroll button 640 d (to enable users to enroll ina provider's plan—e.g, by redirecting users to a particular URL). Theseoptions will be illustrated below with respect to a sample Life Module.It should be noted that these redirected URLs (with respect to the Quote640 c and Enroll 640 d buttons) are utilized in conjunction with oneembodiment of the integration 180 of third-party transaction systems 182(as discussed above with respect to FIG. 1 b) into the presentinvention.

Turning to FIG. 7, UI 700 illustrates one embodiment of a Plan Designtab 710 of Config Tool 175. A user/provider first selects a ProductModule 720, e.g., a Term Life Module, and a particular product or plan730, e.g., the “LifePlan_Cigna_(—)23,” included within that Term LifeModule. In one embodiment, a user/provider would (e.g., based uponinformation associated with the user's login credentials) have accessonly to particular Product Modules and products/plans for which thatuser/provider was authorized. This enables multiple differentthird-party providers to utilize Config Tool 175, but see only their ownproducts/plans. Moreover, even within a particular provider, certainpersons might be authorized to see different subsets of the ProductModules and products/plans.

Having selected a particular Product Module 720 and plan 730, auser/provider could then configure a variety of data 740 associated withthat plan 730. As noted above, many products or plans (and/or categoriesof plan designs) have a great deal of similarity with one another. Bypresenting these common data elements, different providers can easilycustomize this data to reflect the specific details of their plans.

For example, in one embodiment, data 740 includes not only the Name 741of the plan, but also the Calculation 743 employed (e.g., via acalculator widget with an overall cap on the coverage amount, as well asa cap on the customer's salary), including its Type 745 (e.g., an“age-banded” calculation offering different costs and benefits based onthe age range of the customer). In addition, amounts can be entered forMinimum 747 (e.g., 1000) and Maximum 749 (e.g., 500,000) coverage Caps,Guaranteed amounts 751 (e.g., 250,000), a particular level 753 (e.g., 4)of Salary Caps, and an increment 755 (e.g., 10,000) amount separatingthe different coverage levels. Finally, similar data 740 can bespecified for family members, such as spouses (Maximum 757, Minimum 759,Cap 761 and Increment 763) and children (Minimum 765 and Maximum 767).The structure of Module Templates and Plan Designs will be discussed ingreater detail below in order to provide a context in which theconfiguration and customization of this plan data 740 can be betterunderstood.

Turning to FIG. 8, UI 800 of Branding tab 810 of Config Tool 175illustrates one embodiment of a mechanism for enabling differentusers/providers (or perhaps corporations offering products from one ormore providers) to differentiate themselves by branding differentaspects of Product Modules. For example, although a standard set ofcharacters 820 is included by default (e.g., Harvey Keck, the trustedinsurance advisor, along with the Potter family, representing a varietyof different family members with which prospective customers canidentify), a particular provider might desire to specify its ownCharacter Set 820. These custom characters serve not only todifferentiate that provider (or corporation) from its competitors, butmight also enable the provider or company to target particularcustomers, based on industry, demographics, etc., by selectingcharacters having attributes (appearance, behavior, etc) with whichthose desired customers might better identify. A tool for buildingcustom characters from common component parts is also included anddiscussed in greater detail below.

In addition to branding the characters themselves, a user/provider canalso select from among various Company 830 and Character 840 logos thatcan be incorporated within Product Modules at various points, dependingupon the design of Module Templates and their component Elements, asdiscussed in greater detail below.

Finally, turning to FIG. 9, UI 900 of Animation tab 910 of Config Tool175 illustrates the many different aspects of a Product Module (TermLife Module selected via Module dropdown 920) that can be configured andcustomized. In one embodiment, a Table of Contents (TOC 930) is providedto enable a user/provider to select different “scenes” or componentSteps of Term Life Module 920 to configure. As noted above (anddiscussed in greater detail below), when a Module Template is designed,individual Elements can be grouped together into a Step, including forexample some Dialogue (text, audio, etc), Questions, and Animations(including logos and other background visuals).

In this example, Step 1 940 of TOC 930 has been selected, enabling auser/provider to edit or select the Line of text 941 that will bedisplayed initially when Term Life Module 920 is launched. In addition,the accompanying initial Audio 943 (e.g., an introductory speech bytrusted insurance advisor Harvey Keck) and associated Animation 947(e.g., a bicycle crash animation referenced by Harvey) can be selectedfrom among various choices, with the previously selected Logo eithershown or hidden via checkbox 945. Another option might include anextended vignette (via checkbox 949), such as a longer animation withadditional audio, text, etc.

Similar configuration of subsequent Steps (e.g., Step 10 950) is alsoshown, including checkbox 951 to show or hide the previously selectedLogo, and dropdown 953 to select the desired Animation (e.g.,illustrating the General Benefits of Term Life Module 920). In thismanner, a wide variety of different Elements of each Product Module canbe configured and customized. Of course, certain levels of customizationwill require use of Authoring Tool 165 (e.g., creating a completely newAnimation), but many of the most frequently desired modifications can beincorporated into Config Tool 175 as required by the demands ofthird-party providers, corporations and other customers.

III. Configurable Product Modules, Templates and Component Elements

Having discussed the user interface and various features of Config Tool175, it is helpful to understand the underlying structure of ProductModules during which these configurable components are developed. Asnoted above, Module Templates facilitate the development of ProductModules sharing many common Elements, while Plan Designs also includePlan Templates for similar reasons. FIG. 10 illustrates one embodimentof the dynamic runtime flow 1000 among various components of a ProductModule (in this case a Life Module including one or more life insuranceproducts or plans) of the present invention. These Elements and theircomponents can be developed with Authoring Tool 165, and then customizedand swapped for one another via Config Tool 175 both before and afterdeployment (even during runtime in one embodiment) of the ProductModule.

Once the Life Module is deployed, prospective customers areauthenticated by logging into the system (Login 1001) and selecting aProduct Module 1002 (in this case, a Life Module including a particularlife insurance plan). A block diagram of a Life Module Template 1010illustrates key component Elements through which prospective customerscan navigate. The interactive flow is determined by the logic ofControllers, shown in this embodiment as multiple Base Script XML Blocks1012, which include sequential, conditional and event-based logicassociated with individual Elements or groups of Elements, and initiatedby a “main” Controller (not shown) when the Program Module is launched.

A key Element of Life Module Template 1010 is Plan Design Template 1015which in this embodiment employs a JavaScript Object Notation (JSON)script 1017 (for representing simple data structures and arrays) todefine the various data components of the life insurance plan offered toprospective customers. The components of this plan, including a PlanTemplate, are discussed in greater detail below with respect to FIG. 11.Other Elements of Life Module Template 1010 draw upon the components ofPlan Design Template 1015 to educate prospective customers with respectto various aspects of the life insurance plan.

Intro 1020 is the initial Element with which prospective customersinteract. In this example, two different introductory vignettes areincluded—Intro A 1021 (including two Dialogue components) and Intro B1022 (including 3 Dialogue components). Each Dialogue component mightinclude one or more lines of spoken dialogue. Referring back toAnimation tab 910 of Config Tool 175 shown in FIG. 9 above), a providermight select one of these Intro choices using Config Tool 175, dependingupon a variety of factors (type of industry, corporate employer,customer demographics, prospective customer behavior, sell-thru, etc.).In other embodiments, additional and more complex choices can be added,and at various different levels of granularity (e.g., an entire Element,a Step within that Element, a single Dialogue, Audio or Animation, etc).

At runtime, the system displays the selected Intro Element 1020, andplays the associated Intro Audio 1023, which in this example includes achoice of a short 1024 or long 1025 version (implemented as MP3 audiofiles). Note that, in this example, Intro B 1022 also includes thedisplay of an associated Intro Logo 1026, which itself can be tailoredto different companies, illustrated here as a Company A Logo 1027 and aCompany B Logo 1028. Note that such branding could be selected viaBranding tab 810 of Config Tool 175 (see FIG. 8), and coulddifferentiate insurance providers, corporations offering the insurance,etc.

Following Intro 1020, Life Module Template 1010 causes a menu to bedisplayed on the screen, offering prospective customers a choice ofeducational options to explore. These options are illustrated anddiscussed below (starting with FIG. 14) with reference to a Life Moduleexample scenario. The first Element represents the first menu choice,“What Is It?” 1030. Once again, Life Module Template 1010 includes achoice of multiple different Elements from which a user/provider ofConfig Tool 175 can select. In this example, two alternatives areillustrated: a short single-Step Element 1032, or a longer 4-stepElement 1034. Each Step may of course contain multiple componentDialogues (text, audio, visuals, animations, etc.), Questions,Responses, etc.

Another Element in Life Module Template 1010 is Calculator 1035, whichin this example offers a choice among a simple 1036, complex 1037 andmulti-step 1038 calculator. These calculators (e.g., widgets thatimplement particular formulas to calculate numeric amounts, percentages,etc. on given data constants and variables) can be associated withcertain aspects of Plan Design 1015. For example, Calculator 1035 mightbe employed to calculate a life insurance benefit based upon variablessuch as a customer's age, salary or deductible, among other factors.Certain calculations require relative simple formulas, in which casesimple Calculator 1036 might suffice, while other calculations requiremore complex 1037 and even multi-step 1038 Calculators. In otherembodiments, Life Module Template 1010 could include multiple differentcalculators, each selecting from simple, complex, multi-step or othertypes of Calculators.

Just as Life Module Template 1010 includes an Intro Element 1030, italso includes a Closing Steps Element 1040, which might for example,provide some final summary information (not shown) to facilitate theprospective customer's purchase decision. Note that some or all of theElements included in Life Module Template 1010 can be configured andcustomized in Config Tool 175.

In addition, to further simplify the configuration process, the conceptof Presets 1050 enables third-party providers and developers to savelists of multiple different configurations. For example, Preset A 1052(which could be given a more descriptive name) includes 5 differentconfiguration selections: (i) a particular Plan Template (#2), (ii) aparticular “What Is It?” Element (long 4-step Element 1034), (iii)simple Calculator 1036, (iv) long Intro Audio 1025, and (v) Company ALogo 1027. This enables a user/provider of Config Tool 175 to select all5 of these configuration choices with a single selection of Preset A1052. Similarly, Preset B 1054 includes 4 selections (some of whichoverlap with Preset A 1052): (i) Plan Template (#2), (ii) short 1-step“What Is It?” Element 1032, (iii) simple Calculator 1036, and (iv) shortIntro Audio 1024. Other Presets (e.g., Preset n 1056) may also beselected via Config Tool 175.

Finally, a Character Library 1060 (including a database of characterparts) enables third-party providers and developers to configure andcustomize various different aspects of a virtual character's appearanceand behavior. In one embodiment, the ability to customize virtualcharacter attributes is included in Config Tool 175. In others, aseparate tool is provided. In the example illustrated in FIG. 10, auser/provider can select from among 2 different character sets(Character Set A 1070 or Character Set 1075), each of which includesdifferent component parts. Character Set A 1070, for example, includesparts 1073 (implemented in this embodiment as Adobe Flash “SWF”animation files) which can be combined selectively to generate aparticular animation 1071 of that character. Other component parts 1074can be combined selectively to generate a different animation 1072 ofthat same virtual character. Similarly, Character Set B 1075 includescomponent parts 1078 which can be combined selectively to generateanimation 1076, while component parts 1079 can be combined selectivelyto generate animation 1077. A more detailed discussion of CharacterLibrary 1060, and the manner in which these component parts can beselected to generate different animations of the same basic charactersby modifying their appearance and behavior, is set forth below withrespect to FIG. 13.

Turning to the Templates 1100 illustrated in FIG. 11, Life ModuleTemplate 1110 is shown to include the same basic Elements discussedabove with respect to FIG. 10, including Plan Design Template 1115,Intro Element 1120, the “What Is It?” Element 1130 (corresponding to aparticular menu item), Calculator Element 1136 and “Closing Steps”Element 1140, with each Element being driven by a Base Script XML Block1112.

Plan Design Template 1115 in turn includes variables representing commondata components that are utilized to generate various aspects of aparticular life insurance plan, such as Minimum and Maximum coverageamounts 1151, an ageTable data structure 1152 (used, for example, tohold different benefit values associated with different age ranges), aSalary Cap data structure 1153, along with certain Guaranteed Salary Capamounts 1154, a variable number of Annual Pay Periods 1155, values forcovering children 1156, and a host of other data variables that arecommon to particular types of life insurance plans. Where differentproviders offer significantly different types of plans having fewercommon data variables, multiple different Plan Templates can beemployed, again allowing a provider to select among them via Config Tool175.

The Templates 1200 shown in FIG. 12 illustrate the correspondingTemplates 1100 from FIG. 11 (now Life Module Template 1210 and PlanDesign Template 1215), with selected data values filled into thecorresponding template data structures. For example, Intro Element 1120from FIG. 11 is now represented as Intro Element 1220 of FIG. 12, whichincludes the selection of specific Dialogue 1 and Dialogue 2 Elements.“What Is It?” Element 1130 from FIG. 11 is now represented as the“short” version of “What Is It?” Element 1220 of FIG. 12 (e.g., aversion with fewer Dialogues than other alternative versions).Calculator Element 1135 of FIG. 11 now reflects the choice of a simpleCalculator 1235 in FIG. 12. Finally, “Closing Steps” Element 1140 ofFIG. 11 now reflects the selection of a particular “Call Agent” Step1240 as the final Element of Life Module Template 1210 that will bedisplayed to prospective customers.

Moreover, with respect to Plan Design Template 1215, the values of thevarious different types of data have been filled into the correspondingdata structures. For example, data values 1251 include selected amountsfor global, “plan-level” minimum, maximum and guaranteed caps (includingmaximums for children), while data values 1252 include similar amountsfor individual plan members. Data values 1253 include similar amountsfor spouses (including percentage caps and different array levels forspousal coverage), while data values 1254 include coverage amounts andfee multipliers for children. Finally, data values 1255 includemiscellaneous global, “plan-level” values, such as the number of annualpay periods, a decision not to take the spouse's age into account and anage table including coverage multipliers for different age ranges.

IV. Configurable Character Libraries

As referenced above, Character Library 1300 shown in FIG. 13 can bemodified via Config Tool 175 or, in another embodiment, via a separatetool dedicated to the selection of individual character parts. Forexample, a third-party provider or developer might select from amongmultiple different Virtual Character Sets (i.e., libraries of characterparts) 1305, including a default set of standard characters 1310 andother customized character sets, such as Provider 1 characters 1320 andProvider 2 characters 1330.

In one embodiment, each of the Character Sets 1305 contains certain corecomponents, including (i) Bodies, (ii) Body Parts, (iii) Faces; (iv)Costumes; (v) Clothing and (vi) Expressions. These core components aredesigned to be combined to enable the creation of individual virtualcharacters whose identity is retained even when animated exhibitingdifferent appearances and behaviors.

For example, by selecting a particular Body, Body Parts (e.g., hands,legs, etc) and Face, a distinct recognizable virtual character can becreated. That virtual character can then be employed to generatemultiple different animation sequences, exhibiting different behaviors(talking, walking, running, etc.). Moreover, the appearance of thatvirtual character can be modified by altering its Costumes, Clothing andfacial Expressions.

Upon selecting a virtual Character Set 1340, and customizing itsappearance, a provider can then select from among various differentbehaviors in Animation Library 1350. For example, the selected virtualcharacter can be deployed in different poses surrounded by differentprops, and exhibiting various different facial expressions. Standard andcustom animations can be chosen to enable selected virtual characters toexhibit a wide variety of different behaviors.

In addition, background settings for selected virtual characters can beselected from Background Asset Library 1360, including visual assetssuch as buildings, trees, mountains, streets, sidewalks and signposts,as well as background animations. Selections from Animation Library 1350and Background Asset Library 1360 are integrated into vignettes formingFinal Scenes 1370 that will be displayed to prospective customers.

In one embodiment, Final Scenes 1370 include only programmatic data,distinct from the actual assets themselves. Such data include scriptlogic (implemented, for example, in ActionScript) and Frame Labels, andcontrols scene timing as well as the playback of selected animations(including rotations and other translations). A distinct Audio Library1375 is integrated with multiple Final Scenes 1370 to form ProductModules 1380 that ultimately will be deployed to prospective customers.A Suite 1390 of these Product Modules 1380 is then available forsubsequent configuration and customization (before and during runtime)by third-party providers and developers.

Once Product Modules 1380 are completed, they can be deployed on variousdifferent platforms, including web-based or corporate server platforms(such as Server Platform 130 in FIG. 1 a), as well as mobile phones andsocial networks such as Facebook and other Network Platforms 140 thatcan support client or server-based applications.

To illustrate the result of deploying these customized Program Modules1380, an example scenario of a deployed Life Module is depicted in FIGS.14-27 and discussed in greater detail below.

V. Configurable Life Module Scenario

FIG. 14 illustrates an initial screen 1400 displayed after a prospectivecustomer logs into the system, is authenticated and invokes the LifeModule. Note that this Life Module could also be invoked from anothernetwork platform (e.g., a game deployed on a social network or mobilephone which links to a server-based platform on which the Life Module ishosted).

Screen 1400 includes a depiction of a virtual character, in this casetrusted insurance advisor Harvey Keck 1410, who can interact with andeducate the prospective customer regarding a provider's insuranceproducts, and ultimately enable the purchase of such products. Note thatHarvey 1410 is the result of a particular selected combination ofvirtual character parts (face, body, arms, legs, etc), and exhibits adesired appearance (e.g., clothes, glasses, etc) as well as variousanimated behaviors (movements, gestures, etc), along with backgroundvisual elements, such as his desk 1415.

In addition, navigation buttons are displayed to enable the prospectivecustomer to interact with Harvey 1410, and invoke certain functionality.For example, button 1420 will toggle (e.g., mute) the audio, includingHarvey's voice and any background sounds. Button 1430 will display ascene Menu that is discussed with respect to FIG. 16 below. Button 1440navigates backward in the Life Module (e.g., Step by Step back throughdistinct scenes or groups of Elements within Life Module), while button1450 Skips forward through such Steps. At any given moment, rather thanproceeding linearly through the Life Module, the prospective customercan select button 1460 to invoke a Plan Summary scene or button 1470 toEnroll in and purchase one or more of the offered insurance plans.

Upon the launch of the Life Module, the Intro Element will be invoked(discussed with respect to FIGS. 10-12 above), and Harvey 1410 willbegin speaking the selected Dialogue(s), accompanied by any associatedText, Audio, Animations, etc. FIGS. 15 a-15 c illustrate an openinganimation scene in which Harvey 1410 educates the prospective customerregarding the concept of life insurance and the need to protect againstunexpected risks.

Following this introductory scene, a menu screen 1600 (depicted in FIG.16) is displayed, and Harvey 1610 presents the prospective customer withvarious choices with respect to life insurance, such as menu item 1620(“What Is It?”), menu item 1630 (“Why Should I Buy It?), menu item 1640(“How Does It Work?”) and menu Item 1650 (“How Much Should I Buy?”).Each of these choices will be discussed below. Note that these choicesare the result of configuration selections in the Plan Template itself(e.g., via the Config Tool), including the Dialogue that Harvey 1610speaks while menu screen 1600 is displayed.

Should a prospective customer select menu item 1620, then a “What IsIt?” Element would be invoked, illustrated in screen 1700 of FIG. 17. Inthis example, a simple and short animation is played (a snapshot ofwhich is illustrated in FIG. 17), accompanied by Harvey's backgroundaudio summarizing the concept of life insurance (e.g., protectingyourself and your family against the prospect of a “rainy day” orunexpected risk). This example could result from the provider'sselection of a “short” Element, such as Element 1032 depicted in FIG.10.

FIGS. 18-22 illustrate the results of a prospective customer selectingthe “Why Should I Buy It?” menu item 1630 shown in FIG. 16. Screen 1800begins with Harvey 1810 asking the prospective customer to enter his orher age, accompanied by the textual Question 1820 (“How Old Are You?”)and text input box 1830.

In this example, the prospective customer enters “25” in text input box1830, which invokes screens 1910-1950 in FIGS. 19 a-19 f. As a result ofthe provider's selection of various choices for this option, Harveyvoices a Dialogue indicating that the prospective customer falls withinthe “Gen Y” demographic group. The associated animations depicted inFIGS. 19 a-19 f involve other virtual characters in a series ofvignettes accompanied by Harvey's educational Dialogues. Note that thesevignettes are the results of a provider's configuration via the ConfigTool.

For example, Harvey begins by explaining that younger people don'tnecessarily have the same financial responsibilities as do older people(FIG. 19 a), but that benefits can be enjoyed at low group rates (FIG.19 b). Such benefits can include payment of funeral expenses for lovedones (FIG. 19 c), college tuition for a kid brother (FIG. 19 d),contributions to charitable causes such as preventing deforestation(FIG. 19 e), or just putting aside money for a rainy day (FIG. 19 f).

Alternatively, if the prospective customer entered the age of “55,” asshown in input text box 2030 of FIG. 20, a slightly more complex set ofElements is invoked, as illustrated in screen 2100 of FIG. 21. A set of3 menu choices is presented to the prospective customer, accompanied byHarvey's Dialogue indicating that the prospective customer is a “babyboomer” like Harvey. In this example (again as a result of third-partyselections made via the Config Tool), if the prospective customerselects menu item 2130 (“Inheritance For Your Heirs”), then screen 2210of FIG. 22 a is displayed, accompanied by Harvey's explanation that lifeinsurance benefits can be paid to heirs such as aging parents, childrenand others. If menu item 2140 (“Pay For Your Final Expenses”) isselected, then screen 2220 of FIG. 22 b is displayed, accompanied byHarvey's explanation that life insurance benefits can cover funeralcosts, estate administration costs, debts, etc. Finally, menu item 2150returns the prospective customer to the Main Menu on screen 1600 of FIG.16.

FIGS. 23 a-f illustrate the results of a prospective customer selectingthe “How Does It Work?” menu item 1640 shown in FIG. 16. Harvey educatesprospective customers regarding life insurance through a series ofDialogues, including associated animations. For example, Harvey explainsthat Americans are typically underinsured (screen snapshot 2310 of FIG.23 a) and would need to double their life insurance coverage to replace7-10 years of income (screen snapshot 2320 of FIG. 23 b). Harvey notesthat relatively low group rates (screen snapshot 2330 of FIG. 23 c) areavailable to groups, such as employees of a company, due to price breaksoffered to groups by insurance carriers. Harvey goes on to explain(screen snapshot 2340 of FIG. 23 d) the concept of a “guaranteed issueamount”—i.e., the portion of the maximum coverage authorized by theinsurance provider (in this case, $250,000) that is available forpurchase (e.g., the lesser of the $250,000 maximum and 10% of aprospective customer's annual salary). Harvey notes that coverage canalso be purchased for the insured's spouse and children (screen snapshot2350 of FIG. 23 e), and that one need not answer medical questions orobtain a physical exam if they enroll during their employer's“enrollment period” or within 31 days of employment (screen snapshot2360 of FIG. 23 f).

Finally, if a prospective customer selects the “How Much Should I Buy?”menu item 1650, then Harvey asks for information in order to provide anestimate of the appropriate amount of coverage. For example, in screen2400 of FIG. 24, a prospective customer has indicated that he or she is25 years old (input text box 2420), has an annual income of $75,000(input text box 2430) and desires coverage for his or her spouse andchildren (checkboxes 2440). As a result, information is displayed onscreen 2510 of FIG. 25 a showing costs per paycheck for each familymember for a given amount between the plan's minimum and maximumcoverage, and allowing the prospective customer to adjust that amount(control 2515) and see the resulting effect on the cost per paycheck.Once the prospective customer is satisfied with the desired coverageamount (i.e., by selecting the “Done” button 2517), then confirmationscreen 2520 of FIG. 25 b is displayed, providing a summary of thecoverage and cost data, and allowing the prospective customer to enrollin the plan by selecting “Next” button 2525.

Similarly, if the customer indicated (on screen 2600 of FIG. 26) that heor she is 55 years old (input text box 2620), has an annual income of$100,000 (input text box 2630) and desires coverage for his or herspouse and children (checkboxes 2640), then information is displayed onscreen 2710 of FIG. 27 a showing costs per paycheck for each familymember for a given amount between the plan's minimum and maximumcoverage, and allowing the prospective customer to adjust that amount(control 2715) and see the resulting effect on the cost per paycheck.Once the prospective customer is satisfied with the desired coverageamount (i.e., by selecting the “Done” button 2717), then confirmationscreen 2720 of FIG. 27 b is displayed, providing a summary of thecoverage and cost data, and allowing the prospective customer to enrollin the plan by selecting “Next” button 2725.

While particular embodiments of the present invention have beenillustrated and described above, it will be apparent to those skilled inthe art that various modifications may be made in the arrangement,operation and details of the methods and apparatus disclosed hereinwithout departing from the spirit and scope of the present inventiondefined in the claims below.

1. A method for enabling online providers of products and services to customize complex multi-stage transactions with prospective customers, the method including the following steps: (a) hosting on a first set of computers a deployed application that is accessible from a second set of computers by prospective customers of a plurality of online providers offering to sell particular products or services; (b) enabling the online providers to configure, via a third set of computers, one or more runtime assets utilized by the deployed application to personalize interactions with prospective customers; and (c) employing a virtual character in the deployed application on the first set of computers to interact with and educate the prospective customers regarding the characteristics and suitability to the prospective customers of particular products or services offered by the online providers, wherein the interaction is personalized by: (i) the virtual character extracting demographic and behavioral data from the prospective customers; (ii) selecting, based upon the extracted data and configured runtime assets, educational materials as well as particular attributes of the goods and services offered by the online providers; and (ii) presenting the selected educational materials to the prospective customers to facilitate their purchasing decision. 